Ethernet is increasingly popular as a transport network for high speed Wide Area Network (WAN) communications. Various techniques have been developed to enable the deployment of Ethernet transport networks with a mesh topology. This enables the provisioning of diverse paths for traffic protection, and has proven to be popular with network operators and carriers. However, Ethernet requires that traffic forwarding through the network must be controlled to prevent loops.
Spanning Tree Protocol (STP) is frequently used to compute traffic forwarding paths through a mesh network, in such a manner that loops are prevented. In effect, STP converts the mesh network topology into a tree topology. If a network failure (such as a node or link failure) occurs, the tree must be re-computed to re-establish connectivity. In order to prevent network instability and formation of loops during the tree recomputation, all traffic through the tree is terminated until the new tree has been computed, and forwarding state implementing the new tree installed in each node. In large mesh networks, this can require several seconds.
Faster recovery times can be obtained by localizing failures to a particular branch. With this arrangement, the branch of the tree that is directly affected by the detected failure is “pruned”, and a new branch recomputed, starting from the root of the pruned branch. This has an advantage in that only traffic to the nodes directly affected by the network failure is interrupted, while traffic is permitted to flow through the rest of the network. However, in this case, the failure recovery time is dependent on the location of the failure, and the topology of the tree, and so can be unpredictable.
Another approach is to compute two (or more) topologically diverse trees from each node, to every other node. With this arrangement, each node is the “root” of a pair of trees, one of which can be designated as a working tree, and the other as a protection tree. If a network failure affecting the working tree is detected, a failure indication message is propagated to the root node, which can then “switch” traffic to the protection tree. In this case, the failure recovery time is principally dependent on the time required for the failure indication message to propagate to the root node, which can be relatively fast. However, this method requires the computation of a very large number of trees within the network, and it can be very difficult to guarantee topological diversity between the working and protection trees.
For Ethernet transport networks, it would be desirable to obtain failure recovery times comparable to those obtained in physical layer transport technologies such as Synchronous Optical Network/Synchronous Digital Hierarchy SONET/SDH, that is; 50 mSec, or less. In theory, techniques based on the pre-computation of working and protection paths are capable of achieving this level of protection switching performance. However, this performance comes at a cost of great complexity. A simpler solution is desired.
ITU-T SG15/Q9 recommendation G.8032 (February, 2008) describes protection switching in an Ethernet ring. Referring to FIG. 1, an Ethernet ring 2 is an Ethernet network comprising nodes 4 and links 6 connected together in a ring topology. One of the links of the ring is designated as a Ring Protection Link (RPL), and is disabled during normal operation of the ring by placing a channel block 8 on that link. Typically, a channel block 8 is imposed at a node at one end of the RPL. This node may then be referred to as the RPL Owner. In some cases, the channel block 8 may, for example, comprise a policy that prevents packets of the ring from being forwarded through a port hosting the RPL. With such a channel block in place, the ring is guaranteed to be loop free, and conventional Ethernet MAC-learning and path computation can be used to compute forwarding state in each node 4 of the ring 2.
As described in ITU-T recommendation G.8032, a failure of either a link 6 or a node 4 of the ring 2 will be detected by the two nodes nearest the point of failure. Both of these nodes will install a channel block on the port facing the fault and will send a Failure Indication Message (FIM) to their adjacent nodes in the ring. These FIMs will be propagated, in opposite directions, around the ring. Upon receipt of the initial FIM, each node flushes its forwarding database (FDB), and forwards the FIM to the next node on the ring. In addition, the RPL-Owner will remove the channel block 8. This effectively enables connectivity within the ring to be re-established using conventional Ethernet flooding and MAC learning functionality. A convenient aspect of this approach is that the conventional Ethernet flooding behaviour forwards traffic into the ring as the primary mechanism for MAC learning and path computation. As a result, traffic flow within the ring is restored almost immediately after the FDB in each node 4 has been flushed, so that the failure recovery time of the network 2 is dominated by the speed at with the FIMs propagate around the ring. Failure recovery times of 50 msec or less can readily be obtained in practical WANs. However, ITU/T recommendation G.8032 is based on a ring network topology. No comparable scheme is available for implementation in a mesh network.